Business rules logic is an important part of many software systems. Typical solutions of how to implement and manage such rules fall into two categories, each of which has drawbacks.
A first category is home-grown rule definition and management—this can be done natively in the database (DB) using Structured Query Language (SQL), or written in a programming language (e.g. Java™). This has a number of drawbacks, including:
1. poor performance due to lack of rule optimization;
2. maintenance complexity from error-prone programming language syntax that does not naturally lend itself to rule development; and
3. a lack of agility for business users who must document rule change requirements and delegate the implementation to programmers, drastically extending the development cycle.
A second category includes rules engines. Conventional rules engines, although optimized for rule management and execution, also suffer from a lack of business agility. The inputs of rules engine processing can come from a variety of sources and the outputs are similarly variable. To manage input and output object models, a high level programming language is used. While business users might be able to manage the rules themselves, data model management remains a very complex technical undertaking and serious delays can be incurred when the input or output data needs to change.
While homegrown solutions and rules engines are commonly used to solve rule management challenges, neither is perfect. Both options have clear drawbacks in terms of performance, maintenance complexity, agility, or some combination of these factors. The best option is to use a rules engine, but the inherent complexity of managing input or output changes can be a serious roadblock.
A business rules engine is a software system that implements one or more business-related rules. A rule typically has a condition and an action and a business rule is a statement that defines or constrains some aspect of a business. The inputs to a rules engine include a collection of rules (often called a rule execution set) and data objects. The outputs are determined by the inputs and rules.
Rules engine provide a way to manage portions of business logic. There are a variety of rules engines in Java™ and other programming languages. Examples of rules engines include Drools, ILOG JRules, Jess, and others. There are also Java™ based APIs to access rules engines from Java™ platforms.
Using a rules engine in an application may require various initialization and maintenance steps to be performed, such as initializing the rules engine, instantiating working memory, reading rules from a file, adding facts from working memory, and instructing the rules engine to execute the rules. A rules engine wrapper may be used to initialize the rules engine, load the rules from a file system, and execute the rules. However, application classes have to insert facts into working memory and determine output formats, and this requires loading and execution of external resources.
One problem with conventional rules engines is that the conventional implementation paradigm requires considerable development resources to customize the rules engine to deal with input and output changes. As one example, input records may include unstructured or semi-structured data requiring custom code for even minor changes in input and output formulations. In a conventional implementation paradigm this requires significant development resources.
FIG. 1 illustrates some of the problems of using a conventional business rules engine to solve a business problem. As illustrated in FIG. 1, a conventional approach may involve interactions of a customer, a consultant, and a developer. As an illustrative example, seven or more steps may be required using a conventional business rules engine approach. First, in step 101 a customer defines a business need. A consultant then identifies the resources that are required in step 102. A developer then creates and compiles code to provision the new resources in step 103. The consultant then constructs rules to transform addressable resources in step 104. The developer then creates and compiles code to produce a final output in step 105. The consultant then presents the solution to the customer in step 106. The customer then decides to accept the solution in step 107.
The conventional process illustrated in FIG. 1 is slow and labor intensive and requires substantial engineering resources in steps 103 and 107. Consultants can't finish a solution without support from developers. Developers can't anticipate the needs of the consultant in advance of their problem. This creates a time consuming lock step for solving problems with the rules engine. For the consultant to address a new set of facts, a developer must write code to load the facts from a table into a new object because the database table cannot be loaded directly into the rules engine. Writing and compiling code is time consuming, error prone, and an ongoing maintenance cost. Additionally, to produce the final output, code must also be written appropriate to the rules transformation.
Note that in the example of FIG. 1 that there is inherently a lot of customization. However, the approach is also not agile in the sense of permitting easy change and adaptation if changes need to be made to the business rules and/or the data inputs and outputs.
Consider a business scenario where a rule needs to be created to check a variety of field values and trigger an event when those values match some condition. The input records will be obtained from a table called RECORD INPUT:
TABLE 1Record Input TableRECORD_INPUTColNameData TypeKeyVARCHAR2(255)reason1VARCHAR2(255)reason2VARCHAR2(255)notesTextVARCHAR2(4000)
In this example consider a Drools rules engines implementation of a rules engine which may, for example, be implemented on a server. Drools is a business logic integration platform that is an open source, forward chaining production rule system.
Drools is an object-oriented rules engine for Java™. In a Drools implementation the rules are grouped in rule sets, where a rule has a condition and an action. Drools Facts are Java™ beans instances. Drools provides logic (rules) and data (facts) separation that permits rules to be reused across applications.
A Drools engine includes a wrapper object that encapsulates the logic used to access Drools classes. The wrapper may, for example, initialize the rules engine, read rules from a file, add facts to working memory, and instruct the rules engine to execute the rules. The rules engine typically operates as part of a larger system (e.g., a BRMS) that includes a rules editor, rules compiler, runtime, and fact model.
Consider an example of a Drools implementation for a wrapper used to invoke the business rules engine that includes references to the input and output data as well as a rule file to process:
<msequence title=“drools sequence”
xmlns=“http://www.mercedsystems.com/agatha”>                <drools comment=“Business Rules”>                    <table name=“RECORD_INPUT”type=“input”                        class=“com.merced.agatha.javaxform.drools.RecordlnputLoader”/>                    <table name=“RECORD_OUTPUT” type=“output”                        class=“com.merced.agatha.javaxform.drools.RecordOutputPersister”/>                    <rules file=“rules/Sample.drl”/>            <parameter name=“input.table”                        value=“RECORD_INPUT”/>                    <parameter name=“output.table”                        value=“RECORD_OUTPUT”/>        </drools>        
</msequence>
In this example, the wrapper implements a “drools sequence” to implement a set of business rule for device troubleshooting. Table names for the record input and record output are defined. The record input table has a corresponding record input loader whereas the record output has a corresponding record output persister. Note that in the definition, loader and persister classes are hardcoded to compiled objects specific to a given input. The wrapper also includes a rules file, “rules/Sample.drl.” However a disadvantage of this approach is that a separate Java class will usually have to be created and compiled for every input and output table before its information can be reasoned upon by the Drools business rules. This is because it is typically the case that two input tables do not share enough of their column names and types to be addressed by the same loader.
Below is a corresponding rules/Sample.drl file definition to implement a rule for device troubleshooting based on an if-then condition for the input records, including the hardcoded object references:
package callReasonRules;
import droolsCallReasons.InputRecord;
import droolsCallReasons.OutputRecord;
import droolsCallReasons.FactTransform;
global FactTransform transform;
rule “Device Troubleshooting”                when                    $record: InputRecord (                            reason1==“Troubleshooting”                && reason2==“Device”                && notesText not matches “.*broken.*”                                    )                        then                    insert(new OutputRecord($record.getKey( )                        
“Device”, “Device Troubleshooting”));
end
rule “TaggedWriter”                when                    $outputRecord: OutputRecord ( )                        then                    transform.persist($outputRecord);            retract ($outputRecord);                        
end
The tagged records will be written to an output table called RECORD_OUTPUT:
TABLE 2Record Output TableRECORD_OUTPUTColNameDataTypekeyVARCHAR2(255)SummaryVARCHAR2(255)detailVARCHAR2(255)
What's important to note in this example is that both the input object InputRecord and the transformed result object TaggedRecord are defined in compiled code.
However, it's possible that business requirements will change to include new input variables for rule evaluation or include more detail in the output. When that happens, business users cannot immediately use the new inputs or outputs and are instead forced to wait for the technical group to change compiled code. Considering the strict software versioning of enterprise systems, rolling out even simple data model changes that require code modification can suddenly cause weeks or even months of delays.